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1.  Introduction 


The  Three-Dimensional  Wind  Field  (3DWF)  model  is  a  microscale  mass  consistent  diagnostic 
model  (Wang  et  al.,  2005,  2010)  developed  by  the  U.S.  Army  Research  Laboratory.  Its  three- 
dimensional  (3-D)  geo-referenced  (in  latitude,  longitude,  and  altitude)  wind  field  output  can  be 
displayed  in  various  ways  using  the  free  and  popular  Google  Earth™  software.  Google  Earth 
offers  not  only  relatively  accurate  geo-referenced  imagery  that  can  directly  accommodate  the 
3DWF  model’s  3-D  gridded  wind  field  output,  but  also  provides  high  resolution  satellite  imagery 
at  various  levels  of  detail  textured  over  the  application’s  representation  of  the  underlying  terrain. 
In  Huynh  et  al.  (2012),  we  discussed  visualization  of  3DWF  model  output  using  contours  on 
arbitrary  vertical  or  horizontal  cross  sections,  contours  on  terrain-following  surfaces,  wind  vector 
profiles,  and  wind  vector  fields  on  terrain-following  surfaces;  however,  there  is  a  need  to  expand 
the  visualization  capabilities  to  include  isosurfaces  of  model  output,  which  will  enable 
researchers  and  model  users  alike  to  further  investigate  the  behavior  of  the  wind  in  complex 
terrain.  Different  volume  visualization  techniques  have  been  applied  in  many  areas  of  research 
such  as  in  medical  imaging  and  wind  field  modeling.  However,  for  the  scope  of  this  report,  we 
have  adopted  the  popular  “marching  cubes”  (MC)  algorithm  (Lorensen  and  Cline,  1987)  to 
construct  the  triangulated  isosurface  facets  representing  a  constant  surface  of  wind  speed.  An 
excellent  review  of  the  algorithm  is  presented  by  Newman  and  Yi  (2006). 

This  technical  report  documents  the  implementation  of  the  MC  algorithm  to  construct  3-D 
isosurfaces  of  the  magnitude  of  the  three  wind  components  (u,  v,  w),  as  well  as  wind  speed.  In 
order  to  display  model  results  using  Google  Earth,  code  must  be  developed  to  output  the 
isosurfaces  using  Google  Earth’s  Keyhole  Markup  Language  (KML).  The  saved  KML  file  can 
then  be  visualized  using  Google  Earth  or  distributed  through  the  Internet.  This  report  also 
provides  a  brief  description  of  the  design  of  a  user-friendly  graphical  user  interface  (GUI)  menu 
to  assist  the  3DWF  model  users  in  generating  isosurfaces  for  display. 


2.  Isosurface  Extraction  and  Visualization 


Volumetric  visualization  techniques  have  been  applied  in  various  research  fields.  Medical 
imaging  in  particular  has  historically  had  a  specific  need  to  render  volumetric  data  as  surfaces  of 
constant  density.  Other  fields  of  science  and  research  also  have  similar  needs  to  render 
volumetric  data  either  collected  through  experimentation  or  produced  through  modeling.  For 
example,  visualizing  an  isosurface  of  microscale  meteorological  model  outputs,  such  as  wind 
speed,  temperature,  moisture,  or  concentration  fields,  provides  the  model  user  insight  into  the 
behavior  of  these  atmospheric  parameters  over  complex  terrain.  The  MC  algorithm,  first 
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described  by  Lorensen  and  Cline  (1987),  is  a  common  technique  for  extracting  isosurfaces  from 
a  set  of  volumetric  data.  This  algorithm  is  a  sequential-traversal  method,  which,  as  the  name 
implies,  marches  through  a  set  of  cubes  (voxels)  of  gridded  data,  as  shown  in  figure  1.  Lorensen 
and  Cline’s  work  was  done  in  the  medical  imaging  field,  but  the  algorithm  they  describe  can  be 
broadly  applied  to  other  disciplines  where  isosurface  extraction  is  needed.  The  algorithm 
combines  speed  and  simplicity,  through  lookup  tables,  to  extract  one  or  more  triangulated 
surface  facets  that  intersect  the  cube  (voxel).  These  facets  are  then  connected  together  to  form 
the  3-D  isosurface.  The  isosurface  can  then  be  displayed  using  a  visualization  platform  such  as 
the  popular  and  freely  available  Google  Earth. 


Figure  1.  Vertex  and  edge  indexing  of  a  cube. 

2.1  The  Marching  Cubes  Algorithm 

The  fundamental  idea  behind  the  MC  algorithm  is  to  march  through  each  gridded  cube  (voxel) 
one  at  a  time  extracting  facets  of  the  isosurface  that  intersect  that  given  cube.  Summarizing 
Lorensen  and  Cline  (1987)  with  a  slight  modification  for  our  use,  the  algorithm  is  as  follows: 

1.  Read  the  gridded  data  to  be  processed  into  memory. 

2.  Classify  or  categorize  the  type  of  a  given  cube  by  comparing  the  values  of  the  eight 
vertices  to  the  user-specified  surface  constant  assigning  it  an  index. 

3.  Use  the  index  and  a  precomputed  lookup  table  to  determine  which  edges  are  intersected  by 
the  isosurface. 
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4.  For  each  intersected  edge,  compute  the  location  of  the  intersection  using  linear 
interpolation. 

5.  Output  the  triangular  facets  of  the  isosurface  in  KML  format. 

Note  that  we  omit  the  computation  of  the  vertex  normals.  Thus,  following  these  steps,  for  a  given 
set  of  volumetric  data  such  as  gridded  micro-scale  meteorological  model  output,  a  set  of  facets  of 
constant  value  can  be  extracted. 

2.1.1  Gridded  Cube  Classification 

As  illustrated  in  figure  1,  a  cube  is  defined  by  8  vertices  and  the  12  edges  that  connect  the 
vertices.  Following  a  standard  indexing  convention,  we  label  the  vertices  and  edges  as  indicated. 
During  the  extraction  process  in  order  to  classify  a  cube,  each  vertex  is  assigned  two  values:  first 
a  scalar  value  of  the  parameter  that  we  are  interested  in  extracting  isosurfaces  of,  and  second,  a 
Boolean  value  indicating  the  state  of  the  vertex.  The  state  of  the  vertex  is  set  to  1  if  the  vertex  is 
on  or  above  the  isosurface  or  is  set  to  0  otherwise.  Since  the  cube  has  eight  vertices,  we  can 
encode  the  state  of  the  cube’s  vertices  relative  to  the  current  isosurface  value  as  an  eight  bit 

o 

integer.  This  indicates  that  there  are  2  or  256  possible  configurations;  however,  as  discussed  in 
Lorensen  and  Cline  (1987),  this  is  reduced  to  14  patterns  of  facets  using  both  topological  and 
symmetry  arguments.  The  original  algorithm  produces  no  more  than  four  facets  of  the  isosurface 
in  the  current  cube.  Actually,  there  are  15  patterns  if  one  includes  the  null  set,  i.e.,  there  are  no 
facets  of  the  isosurface  intersecting  the  cube  (voxel).  These  patterns,  or  cases,  are  illustrated  in 
figure  2,  where  the  “marked”  vertices  are  below  the  isosurface. 
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Figure  2.  The  15  basic  cube  facetizations  once  reduced  by  topological  and  symmetry  arguments  (Lorensen  and 
Cline,  1987). 

One  must  be  careful  when  implementing  and  using  the  MC  algorithm.  Durst  pointed  out  that 
some  of  the  cases  can  be  faceted  in  multiple  ways.  Since  the  facetizations  for  certain  classes  are 
not  unique,  this  can  lead  to  ambiguities  and  extracted  surfaces  that  are  not  topologically 
consistent.  There  are  seven  classes,  or  cases,  that  have  been  demonstrated  to  be  ambiguous  (see 
e.g.,  van  Gelder,  et  al.  [1994],  Natarajan  [1994],  and  Chernyaev  [1995]).  The  ambiguous  cases 
are  Cases  3,  4,  6,  7,  10,  12,  and  13.  A  common  example  of  a  topologically  inconsistent  isosurface 
due  to  these  ambiguities  is  illustrated  in  figure  3. 


Figure  3.  An  example  of  an  ambiguity  arising  from  topologically  incompatible  facetizations  in  neighboring  grid 

cells.  Panel  (a)  illustrates  the  topologically  inconsistent  surface  when  a  member  of  Case  3  is  adjacent  to  a 
member  of  Case  6,  panel  (b)  is  an  alternate  facetization  of  Class  6,  and  panel  (c)  is  a  topologically 
consistent  surface  created  by  using  the  alternate  facetization. 
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As  illustrated  in  figure  3a,  when  a  member  of  Case  3  (left  cube)  is  adjacent  to  a  member  of 
Case  6  (right  cube),  the  default  facetizations  result  in  a  topologically  inconsistent  surface.  This 
combination  results  in  a  “hole”  in  the  surface.  This  topological  inconsistency  can  be  mended  by 
using  the  alternate  facetization  for  Case  6,  often  labeled  Case  6c,  shown  in  figure  3b  and 
illustrated  in  figure  3c.  It  is  important  to  point  out  that  the  topological  inconsistency  illustrated  in 
figure  3a  does  not  occur  for  all  Case  3  cubes  with  an  adjacent  Case  6  cube.  Recall  that  each  of 
the  cases  has  at  least  two  vertex  configurations  that  result  in  the  same  facetization  due  to 
topological  reduction  arguments.  Here  we  have  used  the  term  “member”  of  a  case  to  indicate  that 
this  is  one  of  the  possible  configurations  that  results  in  topologically  inconsistent  surface. 

Though  not  illustrated,  it  can  be  shown  that  if  the  lower  right  corner  on  the  back  face  of  the 
Case  6  cube  is  above  the  surface  and  the  upper  right  corner  on  the  front  face  of  the  same  cube  is 
below  the  surface,  then  the  default  facetization  will  result  in  a  topologically  consistent  surface. 

2.1.2  Encoding  of  Cube  Vertices  and  Edges 

As  discussed  previously,  the  state  of  the  vertices  of  a  given  cube  can  be  encoded  using  an  8-bit 
integer.  We  can  also  encode  the  state  of  the  edges  of  the  cube  in  a  similar  manner.  Since  there 
are  12  edges,  we  can  encode  each  edge  state  as  intersected  or  not.  This  will  yield  a  set  of  12  bits, 
which  when  ordered  can  be  encoded  as  a  set  of  three  hexadecimal  values.  Figure  4  is  an  example 
of  an  encoded  cube  of  type  Case  1.  The  vertex  marked  vO  is  below  the  isosurface.  From 
inspection,  one  can  see  that  edges  labeled  eO,  e3,  and  e8  are  intersected  by  the  isosurface. 

Tables  1  and  2  are  the  vertex  and  edge  states,  respectively,  for  the  cube  represented  in  figure  4. 
Following  the  encoding  scheme,  a  lookup  table  can  be  created  where  the  index  into  the  lookup 
table  is  given  by  the  vertex  state  and  the  value  is  the  edge  state.  The  lookup  table,  also  referred  to 
as  the  edgeTable  is  provided  in  the  appendix. 


Figure  4.  Isosurface  facet  for  type  Case  1 ,  where  the  marked  vertex  vO  is 
below  the  isosurface. 
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Table  1.  Example  of  a  cube  vertex  encoding  for  Case  1  type  cube  represented  in  figure  4. 


Vertex  Index 

v7 

v6 

v5 

v4 

v3 

v2 

vl 

vO 

Bit  (above/below) 

0 

0 

0 

0 

0 

0 

0 

1 

1 

Table  2.  Example  of  a  cube  edge  encoding  for  Case  1  type  cube  represented  in  figure  4. 


Edge  Index 

ell 

elO 

e9 

e8 

e7 

e6 

e5 

e4 

e3 

e2 

el 

eO 

Encoded 

Hex 

Value 

Bit 

(intersected/not) 

0 

0 

0 

1 

0 

0 

0 

0 

1 

0 

0 

1 

Hex  Value 

0x100 

0x000 

0x009 

0x109 

2.1.3  Locating  Isosurface  Intersection  on  Marked  Edges  and  Facet  Orientation 

Referring  to  figure  4  in  the  previous  example,  we  note  that  the  three  vertices  of  the  facet  are  the 
intersection  points  marked  tO,  t3,  and  t8,  which  are  on  edges  eO,  e3,  and  e8,  respectively.  There 
are  two  things  that  must  be  done  before  the  facet  is  fully  defined:  (1)  locate  the  intersection  point 
of  the  isosurface  on  the  edge  and  (2)  determine  the  ordering  of  the  vertices  of  the  triangle.  The 
first  can  be  accomplished  using  a  simple  linear  interpolation  to  be  described  below  and  the 
second  depends  on  whether  the  marked  vertex  is  above  or  below  the  surface. 

For  the  microscale  meteorological  model  referred  to  previously,  the  grid  is  a  standard  Cartesian 
grid.  We  can  locate  any  point  in  the  domain  by  the  tuple  (x,y,z).  Thus,  for  figure  4,  we  can 
represent  vertex  vO  by  its  tuple  (xvo,  yvo,  zvo).  The  adjacent  vertices  can  be  represented  in  a 
similar  fashion.  Furthermore,  for  scalar  values  on  the  model  grid  we  define  the  value  anywhere 
along  the  connecting  edge  of  two  vertices  as 

s(x,  y,  z)  =  S'A  _  —  (x  -  xv0 )  +  sv0 .  (1) 

•T’l  ~  xvo 


Since  5  is  known,  solving  for  x  yields 


v  = 


(*vl  -*voX*-0 


Vv0  * 


(2) 


This  same  derivation  holds  true  for  both  y  and  z  as  well.  Therefore,  we  represent  the  intersection 
point  along  any  edge  as  follows: 
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(3) 


v  (•*'■!  ,  r 
XtO  ~  XvO’ 

^vl-^vO 

„  _  ()7l  -yvoXS~Svo)  ,  „ 

Jt  0  —  +  /  vO 

*vl  -  Uo 

(Zvl-ZvoXS~Svo)  ,  _ 

ZtO  -  - +  ^vO- 

5vl  "5vO 

In  practice  we  also  consider  how  close  the  isosurface  is  to  a  given  vertex  in  value,  as  well  as  how 
near  in  value  two  adjacent  vertices  are.  So  if  [s  -  sv0|  <  le  5  or  | svl  -  .vv0  <  le  5 ,  then  we  assign 

the  point  of  intersection  as  (xv0,  yvo,  zv0). 

2.2  Programming 

In  order  to  expand  the  capabilities  of  our  current  modeling  and  visualization  framework  (Huynh 
et  al.,  2012)  we  implemented  the  MC  algorithm  and  extended  capabilities  of  the  GUI  as 
described  in  this  section. 

2.2.1  Implementation  of  Marching  Cubes  Algorithm  in  Fortran90 

While  the  original  exposition  by  Lorensen  and  Cline  (1987)  regarding  MC  limited  the  number  of 
facets  to  four,  we  have  chosen  to  adopt  and  implement  a  revised  method  discussed  and  made 
available  by  Bourke  (1994),  which  can  accommodate  up  to  five  facets  for  a  given  grid  cube. 
While  the  published  code  from  Bourke  (1994)  is  in  the  public  domain,  it  was  originally 
implemented  in  the  C++  programming  language  as  part  of  a  facet  extraction  and  display  program 
using  the  OpenGL  application  programming  interface.  For  our  purposes,  it  was  advantageous  to 
port  the  algorithmic  portion  of  this  code  using  Fortran90.  Porting  the  algorithmic  portion  of  the 
C++  code  to  Fortran90  was  relatively  straightforward.  Figure  5  is  an  example  of  a  test  case  that 
was  used  to  confirm  that  the  porting  and  implementation  of  the  algorithm  to  Fortran90  was 
consistent  and  correct.  Figure  5  is  the  rendering  of  a  sphere  extracted  from  a  simple  data  set 
displayed  within  the  Google  Earth  framework. 
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Figure  5.  Isosurface  of  a  simple  sphere  displayed  within  Google  Earth. 

The  implementation  of  MC  presented  here  takes  as  input  the  “isovalue”  to  be  faceted  and  the 
model  grid  variable  to  be  processed.  Once  the  model  output  has  been  processed  an  output  file  is 
produced,  which  contains  the  isosurface(s)  encoded  in  KML.  This  file  can  then  be  read  into 
Google  Earth  and  visualized.  Listing  1  is  an  excerpt  of  a  typical  output  for  the  isosurface 
extraction.  The  excerpt  contains  a  single  facet  represented  as  a  single  <Polygon>  element  in 
KML,  an  <ScreenOverlay>  element  to  indicate  the  scale  or  magnitude  of  the  isosurface,  and  a 
<Camera>  element  to  facilitate  an  initial  viewing  angle.  We  also  implemented  the  capability  to 
observe  the  time  evolution  of  the  isosurface. 


8 


Listing  1 .  Excerpt  from  KML  file  produced  using  the  implementation  of  MC  algorithm. 


KML  Preamble 

<?xml  version="1.0"  encoding="UTF-8"?> 

<kml  xmlns="http://earth. google. com/kml/2.2"> 

<Folder> 

<name>Frame  with  TimeSpans</name> 

Facet  using  KML 
<Polygon> 

<Placemark> 

<Style> 

<PolyStyle><color>DD0080FF</color><outline>0</outline><fill>l</fill> 

</PolyStyle> 

</Style> 

<visibility>  1  </visibility> 

<Polygon> 

<extrude>0</extrude><altitudeMode>relativeToGround</altitudeMode> 

<outerBoundaryIs><LinearRingxcoordinates> 

68.9885101318359,34.4565925598145,618.657104492188 

68.9885101318359.34.4565620422363.620 

68.9884872436523.34.4565925598145.620 
68.9885101318359,34.4565925598145,618.657104492188 
</coordinates></LinearRingx/outerBoundaryIs> 

</Polygon> 

</Placemark> 

Excerpted 

Scale  using  KML 
<ScreenOverlay> 

<ScreenOverlay> 

<Iconxhref>file  :///C  :/3D  WF/wspdspec  .j  pg</hrefx/Icon> 

<overlayXY  x="l"  y="0.45"  xunits="fraction"  yunits="fractionM/> 

<screenXY  x='T"  y="0.45"  xunits=”fraction"  yunits=" fraction 7> 

<rotationXY  x="0"  y="0"  xunits=" fraction"  yunits="fraction"/> 

<size  x="0"  y="0"  xunits="fraction"  yunits="fraction"/> 

</S  creenO  verl  ay> 

Initial  Viewpoint 
using  KML 
<Camera> 

<Camera> 

<longitude>68.97  </longitudexlatitude>34.43 

</latitudexaltitude>  1 5000</altitude> 
<range>30000</rangextilt>5</tiltxheading>0</heading> 

</Camera> 

KML  Termination 

</Folder> 

</kml> 

2.2.2  GUI  and  Google  Earth  Display 

As  in  Huynh  et  al.  (2012),  we  have  implemented  this  extension  to  the  modeling  system 
capabilities  using  a  combination  of  Fortran90  modules  and  a  GUI  using  HyperText  Markup 
Language  version  4  (HTML  v4)  and  JavaScript  (JS).  Figure  6  is  a  screen  capture  of  the  GUI  used 
to  extract  an  isosurface  from  a  3DWF  model  grid. 
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Figure  6.  GUI  for  isosurface  extraction. 

The  GUI  takes  input  from  the  user  requesting  information  such  as  the  model  output  file  to  be 
processed,  which  scalar  field  to  extract  an  isosurface  of,  and  what  the  desired  isosurface  value  is. 
The  initial  viewpoint  is  taken  as  the  center  of  the  3DWF  model  domain  with  the  domain 
coverage  indicated  by  a  yellow  bounding  square.  The  user  can  also  process  a  number  of  model 
output  files  to  produce  an  isosurface  that  evolves  with  time.  The  resultant  animation  from  this 
feature,  however,  is  quite  resource  intensive  when  visualized  within  Google  Earth  application 
and  its  use  is  not  recommended  at  this  time. 

Once  the  processing  of  the  model  data  is  completed  and  a  KML  file  has  been  generated  the 
output  the  file  containing  the  isosurface(s)  can  be  visualized  within  Google  Earth.  Two  examples 
of  extracted  isosurfaces  are  given  in  figures  7  and  8. 
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Figure  7.  Isosurface  display  of  3  m/s  wind  speed  for  a  model  domain  volume  of  10x10x4  km. 
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Figure  8.  Isosurface  display  of  6  m/s  wind  speed  for  the  same  domain  in  figure  7. 

Figure  7  displays  the  isosurface  of  3  m/s  wind  speed  over  a  model  domain  near  Kabul, 
Afghanistan,  diagnosed  by  the  3DWF  model.  Figure  8  is  identical  in  space  and  time  to  figure  7 
except  an  isosurface  with  a  value  of  6  m/s  is  displayed.  The  3DWF  model  grid  used  in 
figures  7  and  8  covered  10x10x4  km  (with  dx=dy=50  m  and  dz=20  m).  As  expected,  with  higher 
wind  speeds  aloft,  the  vertical  extent  of  the  3  m/s  isosurface  extends  from  258  to  1560  m  above 
the  lowest  terrain  elevation  in  the  model  domain  (1891  m  above  sea  level  [ASL]),  while  the 
6  m/s  isosurface  had  a  greater  extent  starting  at  600  m  above  the  lowest  model  terrain  elevation 
extending  to  3980  m  over  the  same  elevation. 

The  color  scale  to  the  right  is  produced  using  the  <ScreenOverlay>  KML  element.  It  has  64 
levels  of  resolution  with  the  maximum  and  minimum  values  mapped  to  the  maximum  and 
minimum  values  of  the  scalar  that  is  being  visualized.  The  place  marker  also  gives  the  value  of 
the  extracted  isosurface  that  corresponds  to  the  color  scale  to  the  right.  The  Google  Earth 
Timescale  element  is  also  used  to  indicate  the  model  valid  time  for  the  displayed  data.  This  can 
also  be  used  to  animate  the  isosurface  in  time  if  the  user  has  enabled  that  feature  of  the  extraction 
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tool.  The  Timescale  tool  can  be  operated  manually  by  the  user  to  advance  the  evolution  of  the 
isosurface  in  time  or  set  it  to  automatically  advance.  Using  the  Google  Earth  navigation  tools,  the 
user  can  observe  the  extracted  isosurface  from  many  different  views  to  analyze  the  underlying 
data.  The  Google  Earth  platform  provides  visual  context  to  the  3DWF  model  user.  This  context 
is  especially  useful  in  areas  with  complex  terrain  or  significantly  built  up  urban  and  suburban 
area.  The  visual  context  also  provides  users  with  indications  as  to  why  the  model  output  is 
behaving  as  it  is,  for  example,  is  there  an  object  that  may  be  damming  or  retarding  the  flow 
field? 

2.2.3  Visualizing  Scalar  Data  in  General 

The  development  of  this  isosurface  extraction  module  is  not  limited  to  model  grid  output  from 
the  3DWF  or  Atmospheric  Boundary  Layer  Experiment  (ABLE)  model  output.  This  extraction 
utility  can  be  extended  to  process  concentration  fields  provided  by  a  dispersion  model. 

Figures  9  and  10  are  examples  of  this  extension. 
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Figure  9.  Extended  GUI  for  Isosurface  extraction  of  concentration  or  temperature. 
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Figure  10.  Isosurfaces  of  a  contaminate  plume  with  surface  generated  for  0.001,  0.003,  and  0.005  pg/m3. 

Figure  9  is  an  extended  GUI  to  accommodate  the  extraction  of  scalars  in  general.  In  particular 
the  GUI  has  been  extended  to  extract  isosurfaces  of  scalars  such  as  plume  concentration  and 
temperature.  Figure  10  is  the  display  of  three  isosurfaces  of  a  modeled  contaminate  plume.  There 
are  three  isosurfaces  that  are  displayed  with  the  isovalue  set  to  0.001,  0.003,  and  0.005  pg/m3. 
The  facets  include  an  alpha  channel  for  translucent  rendering. 
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3.  Conclusion 


In  support  of  performance  and  capability  improvement  of  the  3DWF  model,  we  previously 
developed  a  3-D  visualization  system  using  Google  Earth  as  our  scientific  visualization  platform. 
This  system  was  capable  of  displaying  horizontal  and  vertical  cross  sections  of  model  wind  field 
output,  vector  wind  profiles,  and  a  vector  wind  field  on  a  terrain-following  surface.  Through  the 
adoption  of  Google  Earth  as  a  visualization  platform,  we  provided  the  user  with  visual  context  of 
the  3DWF  model  output.  In  this  report,  we  have  documented  the  extension  of  visualization 
capabilities  by  implementing  the  MC  algorithm  for  isosurface  extraction  and  visualization.  The 
isosurface  extraction  capability  was  not  limited  to  the  output  from  the  3DWF  model,  but  was 
extended  to  include  other  scalar  output  such  as  contaminate  concentration  plumes  and 
atmospheric  temperatures. 
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Appendix.  edgeTable  and  triTable  Lookup  Tables 


Tables  A-l  and  A-2  provide  the  lookup  tables  used. 
Table  A-l.  edgeTable  listing  the  256  possible  edge  intersections 


0 

x'000' 

x'109' 

x'203' 

x'30a' 

x'4061 

x'50f 

x’605’ 

x'70c’ 

1 

x'80c' 

x'905' 

x'aOf 

x'b06' 

x'cOa' 

x'd03' 

x’e09’ 

x’fOO’ 

2 

x'190' 

x'099' 

x’393’ 

x'29a' 

x’596’ 

x’49f 

x’795’ 

x'69c' 

3 

x’99c’ 

x'895' 

x’b9f 

x'a96' 

x'd9a' 

x'c93' 

x’f99’ 

x’e90’ 

4 

x'230’ 

x'339' 

x’033’ 

x'13a' 

x'636' 

x'73f 

x’435’ 

x'53c' 

5 

x'a3c' 

x'b35' 

x'83f 

x'936' 

x'e3a' 

x’f33’ 

x'c39’ 

x’d30’ 

6 

x'3a0’ 

x'2a9' 

x'la3' 

x'Oaa' 

x'7a6' 

x'6af 

x’5a5' 

x’4ac’ 

7 

x’bac' 

x'aa5' 

x'9af 

x'8a6' 

x'faa' 

x'ea3’ 

x’da9’ 

x’caO’ 

8 

x'460' 

x'569' 

x'663' 

x'76a' 

x'66' 

x'16f 

x'265’ 

x'36c' 

9 

x'c6c' 

x'd65' 

x'e6f 

x'f66' 

x'86a' 

x’963' 

x’a69’ 

x’b60’ 

10 

x’5f0’ 

x4f9’ 

x'7f3’ 

x'6fa' 

x'lf6' 

x’Off 

x'3f5’ 

x’2fc’ 

11 

x'dfc1 

x'cf5' 

x’fff 

x'ef6' 

x'9fa' 

x’8f3’ 

x'bf9’ 

x’afO’ 

12 

x’650' 

x'759' 

x'453’ 

x'55a' 

x’256’ 

x'35f 

x’055’ 

x'15c' 

13 

x'e5c' 

x'f55' 

x'c5f 

x'd56' 

x'a5a' 

x'b53’ 

x’859’ 

x’950’ 

14 

x'7c0' 

x'6c9' 

x’5c3' 

x'4ca' 

x’3c6' 

x'2cf 

x'lc5’ 

x’Occ’ 

15 

x'fcc' 

x'ec5' 

x’dcf 

x'cc6' 

x'bca' 

x'ac3' 

x’9c9’ 

x’8cO’ 

16 

x'8c0' 

x'9c9' 

x'ac3' 

x'bca' 

x'cc6' 

x’dcf 

x’ec5’ 

x’fcc’ 

17 

x'Occ' 

x'lc5' 

x'2cf 

x'3c6' 

x'4ca' 

x'5c3’ 

x’6c9’ 

x’7c0’ 

18 

x'950' 

x'859' 

x'b53’ 

x'a5a' 

x'd56' 

x'c5f 

x’f55’ 

x’e5c’ 

19 

x'15c' 

x'055' 

x'35f 

x'256' 

x'55a' 

x'453' 

x’759’ 

x’650’ 

20 

x’afO’ 

x’bf9’ 

x'8f3’ 

x'9fa' 

x'ef6' 

x’fff 

x'cf5’ 

x’dfc’ 

21 

x'2fc’ 

x'3f5' 

x’Off 

x'lf6' 

x'6fa' 

x'7f3’ 

x'4f9’ 

x’5fO’ 

22 

x'b60' 

x'a69' 

x’963’ 

x'86a' 

x'f66' 

x’e6f 

x’d65’ 

x'c6c' 

23 

x'36c' 

x'265' 

x'16f 

x’066' 

x'76a' 

x’663’ 

x'569’ 

x’460’ 

24 

x'caO' 

x'da9' 

x’ea3' 

x'faa' 

x'8a6' 

x'9af 

x’aa5’ 

x’bac’ 

25 

x'4ac' 

x'5a5' 

x'6af 

x'7a6' 

x'Oaa' 

x'la3’ 

x'2a9’ 

x'3aO’ 

26 

x’d30’ 

x'c39’ 

x’f33' 

x'e3a' 

x'936' 

x’83f 

x'b35’ 

x’a3c' 

27 

x'53c' 

x'435’ 

x’73f 

x’636’ 

x'13a' 

x’033’ 

x'339’ 

x'230’ 

28 

x’e90’ 

x’f99’ 

x'c93' 

x'd9a' 

x'a96' 

x'b9f 

x’895’ 

x'99c' 

29 

x’69c' 

x’795’ 

x’49f 

x'596' 

x'29a' 

x'393’ 

x’099’ 

x'190’ 

30 

x’fOO’ 

x'e09’ 

x'd03' 

x'cOa' 

x’b06' 

x'aOf 

x’905’ 

x’80c’ 

31 

x'70c' 

x'605' 

x’50f 

x’406' 

x’30a' 

x'203’ 

x'109’ 

x’OOO’ 

Table  A-2.  triTable  listing  the  ordered  edge  connection  graph  for  each  fac 


128 


129 

130 

131 

132 

133 

134 

135 

136 

137 

138 

139 

140 

141 

142 

143 

144 

145 

146 

147 

148 

149 

150 

151 

152 

153 

154 

155 

156 

157 

158 

159 


x'8c0' 

x'9c9' 

x'ac3’ 

x'bca' 

x'cc6' 

x'dcf 

x'ec5' 

x'fcc' 

x'Occ' 

x'lc5' 

x’2cf 

x'3c6’ 

x'4ca' 

x'5c3' 

x'6c9' 

x7cO' 

x'950' 

x'859' 

x'b53' 

x'a5a' 

x'd56' 

x'c5f 

x'f55' 

x'e5c' 

x'15c' 

x'055' 

x'35f 

x'256' 

x'55a’ 

x'453' 

x759' 

x'650' 


List  of  Symbols,  Abbreviations,  and  Acronyms 


3-D 

three-dimensional 

3DWF 

three-dimensional  Wind  Field 

ABLE 

Atmospheric  Boundary  Layer  Experiment 

ASL 

above  sea  level 

GUI 

graphical  user  interface 

HTML 

HyperText  Markup  Language 

JS 

JavaScript 

KML 

Keyhole  Markup  Language 

MC 

marching  cubes 

24 


NO.  OF 

COPIES  ORGANIZATION 

1  ADMNSTR 

(PDF)  DEFNS  TECHL  INFO  CTR 
ATTN  DTICOCP 

8725  JOHN  J  KINGMAN  RD  STE  0944 
FT  BELVOIR  VA  22060-6218 

2  US  ARMY  RSRCH  LAB 
(PDFS)  ATTN  RDRL  CIO  LL  TECHL  LIB 

ATTN  IMAL  HRA  MAIL  &  RECORDS  MGMT 
ADELPHI  MD  20783-1197 

8  US  ARMY  RESEARCH  LAB 
(HCS)  ATTN  RDRL  CIE  D 
1  G  HUYNH  (5  HCS,  1  PDF) 

(PDF)  Y  WANG  (1  HC) 

C  WILLIAMSON  (1  HC) 

P  CLARK  (1  HC) 

ADELPHI,  MD 

6  US  ARMY  RESEARCH  LAB 
(HCS)  ATTN  RDRL  CIE  D 

1  S  O’BRIEN  (5  HCS,  1  PDF) 

(PDF)  G  VAUCHER  (1  HC) 

BLDG  1622 

WHITE  SANDS  MISSILE  RANGE 
NM  88002-5501 
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